Rugalmas adatbetöltők készítése (Package configuration)

Az Integration services „Package configuration” szolgáltatása megteremti annak lehetőségét, hogy az adattárház betöltő SSIS csomagok fontosabb paramétereit, futási környezetét, adatforrásainak elérési útját, és még sok minden mást külső állományokon keresztül konfigurálhassunk. (hasonlóan a régi ini fájlokhoz)

Képzelje el, hogy egy elérési út megváltozik. Ha ez az elérési utak bele vannak égetve az SSIS csomagokba, akkor az összes SSIS csomagot át kell írnia. Ha az elérési utat egy külső fájlban tárolja, akkor elég a külső fájlban átírnia.

Megj.: Az integration Services (SSIS) kétféle lehetőséget biztosít az SSIS csomagok tulajdonságainak megváltoztatására: A package configration szolgáltatással az SSIS csomagok tulajdonságait futás előtt tudjuk megváltoztatni, míg a property expression szolgáltatással futás közben is. Jelen cikk csak az SSIS package configuration szolgáltatásával foglalkozik.

Milyen paramétereket konfiguráljunk kívülről?

Az adatforrások jellemzőit: (Ezt mindig) Forrás szerverek neve, IP címe, adatbázisok, fájlok nevei, elérési útjai,… Egyszóval a forrás- és cél rendszerek connection string-jeit. Ezek azok a jellemzők, amelyek az adattárház vagy üzleti intelligencia rendszer életciklusa alatt változhatnak, és amelyeket a fájdalmas lekövetés elkerülése érdekében mindenképpen külön állományban célszerű tárolnunk.

Az adatforrás jellemzőin kívül – egyes esetekben – célszerű lehet konfigurációs állományba helyezni az SSIS csomagok teljesítményét befolyásoló paramétereket is. Hány betöltési folyamat, SSIS package vagy task fusson párhuzamosan? 4 vagy 10? Ki döntse ezt el? Az SSIS vagy mi?

Ha eltérő hardvereken futtatjuk ugyanazon adattárház betöltő SSIS csomagokat (teszt, fejlesztői és éles környezetek), vagy számítunk arra, hogy az adattárház szerverét előbb utóbb upgrade-elni fogjuk (új processzor/processzorok, több memória), akkor célszerű külső konfigurációs állományba helyezni az SSIS package futási paraméterinek egy részét is. Ilyen például a MaxConcurrentExecutables tulajdonság is, amellyel a párhuzamosan futó feladatok számát befolyásolhatjuk.

Mikor használjuk a "package configuration" szolgáltatást?

A válasz: mindig. Ha az éles szervertől elkülönülő szervereken fejlesztünk, tesztelünk, akkor ezt kulturáltan máshogy meg sem tudnánk oldani.

Ha csak egy szerveren dolgozunk, akkor is szükséges a konfigurációs adatok külön állományban történő tárolása, mert előfordulhat, hogy a szerver meghibásodik, elöregszik, és át kell majd mindent pakolni egy másik gépre. (és jó lenne, ha nem kéne minden SSIS csomagot emiatt átírni)

De saját szerverünk paraméterein kívül, a forrásrendszerek tulajdonságai is megváltozhatnak, (elérési utak, szerver nevek, …) ami szintén azt indokolja, hogy használjuk a „package configuration” szolgáltatást.

Hol tároljuk a konfigurációs paramétereket?

Az Integration Services öt különböző lehetőséget kínál a konfigurációs paraméterek tárolására. Ezek:

• XML configuration file
• Environment variable
• Registry Entry
• Parent package variable
• SQL Server

SSIS csomagok konfigurációs paramétereink tárolási lehetőségei

Vajon adattárházas, vagy üzleti intelligencia környezetben melyik tárolási módot célszerű választani? Milyen előnyei, hátrányai vannak az egyes tárolási módoknak? A következő fejezetek erre keresik a választ.

XML configuration file

Az xml konfigurációs fájl egy *.dtsconfig kiterjesztésű szöveges állomány, amely xml formátumban tartalmazza a konfigurációs beállításokat. Ezt az XML fájlt az SSIS a Package Configuration Wizard segítségével legyártja nekünk.

A *.dtsconfig xml konfigurációs fájl felépítése

Mit konfiguráljuk egy XML fájlban? Illetve egy fájlban konfiguráljunk-e mindent, vagy konfigurálandó paraméterenként (tulajdonságonként) hozzunk létre egy-egy XML fájlt? (pl.: egy adatforrás egy XML konfigurációs fájl?)

A válasz egyértelműen több kicsi konfigurációs fájl. Az a legjobb, ha minden egyes adatforrást, minden egyes SSIS tulajdonságot külön XML fájlokon keresztül konfigurálunk. Miért? Mert nem minden SSIS package használja az összes adatforrásunkat, és ha a konfigurációs fájl olyan objektumra hivatkozik, amely nem található meg az SSIS package-ben, akkor az SSIS hibát jelez. (Az adattárház betöltő SSIS csomagok futni fognak, de a BI Development Studio hibát fog jelezni)

XML fájl előnye, hogy könnyen szerkeszthető, egyszerűen kezelhető. Hátránya, hogy az adattárház betöltő SSIS csomagokba be kell égetnünk a konfigurációs fájl elérési útját, és ha egy másik gépen nem létezik ez az elérési út, akkor ugyanúgy át kell írnunk az összes SSIS csomagot, mintha nem használtunk volna konfigurációs fájlt…

Hogy elkerüljük a konfigurációs fájl elérési útjának beégetését, az SSIS lehetőséget biztosít arra, hogy az XML konfigurációs fájl elérési útját egy úgynevezett Windows környezeti változóban (Environment variable) tároljuk. (Configuration location is stored in an environment variable). Így megoldható, hogy a konfigurációs beállításokat egy fájlban tároljuk, de a fájl elérési útját egy Windows környezeti változóban.

Environment variable

Az SSIS képes a Windows környezeti változóinak (Environment variable) olvasására, és képes a változó tartalma alapján konfigurálni futás előtt az adattárház betöltő SSIS csomagokat.

A környezeti változók Windows operációs rendszer változói. Környezeti változókat mi magunk is létrehozhatunk, és azt felhasználhatjuk különböző értékek tárolására. (Hogyan: My compurer-> properties -> advanced fül -> Environment variables)

A környezeti változók előnye, hogy „elérési útjuk” minden gépen ugyanaz, így nem kell félnünk attól, hogy egy másik gépen esetleg nem tudjuk létrehozni ugyanazt az elérési utat (mint például xml fájlok esetén). Hátránya, hogy az XML fájlnál nehezebben kezelhető és nincs hozzá felület, amin keresztül a változók és tartalmuk menthetők és visszaállíthatóak lennének.

Registry Entry

A registry a Windows operációs rendszer saját adatbázisa. Hasonlóan a környezeti változókhoz, a registry-be is fel tudunk venni saját változókat (kulcsokat), amelyek értékét fel fogjuk tudni használni az adattárház betöltő SSIS csomagok konfigurálására.

Parent package variable

Egy konfigurációs beállítást függővé tehetünk egy másik (hívó, szülő) SSIS package változójának tartalmától. Mikor lehet ez hasznos? Tipikusan olyan esetekben, amikor a gyerek SSIS package változójának akarunk értéket adni a szülő SSIS package egy változójának értéke alapján.

Tegyük fel hogy, van egy „master” SSIS package-ünk amely vezérli a teljes betöltési folyamatot: megfelelő sorrendben meghívja a betöltést végrehajtó elemi (gyerek) SSIS csomagokat. Párhuzamosan, amit párhuzamosan lehet, sorosan, ahol számít, hogy mely SSIS csomagnak kell előbb futnia, és mely SSIS csomagnak kell később. Azt, hogy mely napokat kell leválogatni a forrásrendszerből, a master SSIS package egy ExtractDate nevű változója tartalmazza. Induláskor kitöltjük a master SSIS package ExtractDate változóját, és a gyerek package-ek futásuk előtt kiolvassák a „master” (szülő) SSIS package-ből, hogy mely napok adatait kell leválogatni.

A megoldás hátulütője, hogy a gyerek SSIS package-ek nehezen futtathatóak a szülő SSIS package futtatása nélkül. Lásd: Látja a gyerek SSIS package a szülő SSIS package változóit?

SQL Server

Az SSIS lehetőséget biztosít arra, hogy az adattárház betöltő SSIS csomagok a konfigurációs beállításokat egy táblából olvassák fel. (A táblát az SSIS egy általunk meghatározott adatbázisba legenerálja)

Az SQL Servert a konfigurációs beállítások tárolására használni nem a legszerencsésebb, mert az SQL Server maga is egy adatforrás, így ha adatforrást akarnánk konfigurálni, akkor az adatforrás írná le, hogy hol található az adatforrás…

Persze előnnyel is kecsegtethet az SQL Serverben tárolni bizonyos konfigurációs beállításokat, hiszen az adattárházhoz, vagy az adatpiachoz amúgy is használunk már konfigurációs adatbázist, ami vezérli a betöltési folyamatainkat, és ezt az adatbázist rendszeresen mentjük, esetleg auditáljuk.

Ha connection sztringünk tartalmazza a forrásrendszerek eléréséhez szükséges felhasználónevet és jelszót, akkor az adatbázisban történő tárolással biztosíthatjuk a felhasználónév és jelszó biztonságos tárolását, bár ugyanezt az eredményt elérhetjük xml konfigurációs fájlokkal is, ha azokat egy szűkített jogosultságú könyvtárban tároljuk.

Melyik a legjobb választás?

Úgy gondolom, hogy adattárházas környezetben tisztán egyik tárolási mód sem ad kielégítő megoldást. A fenti tárolási módok közül talán az XML tárolási mód a legjobb de az XML konfigurációs fájlnak is van elérési útvonala, és ha az megváltozik, akkor ugyanúgy át kéne írnunk SSIS csomagjainkat, mintha nem is használnánk konfigurációs fájlt.

A Windows környezeti változók elérési útja sosem változik meg, de ott tárolni az összes környezeti változó értékét meglehetősen nehézkes, hiszen nincs hozzá szép felület és menedzseléséhez speciális jogosultságokra lehet szükség.

Megoldás: Indirect XML Configuration file

A legjobb megoldás két konfigurációs eljárás kombinációja: Az SSIS csomagokat XML fájlokon keresztül konfiguráljuk, és ezen XML konfigurációs fájlok elérési útvonalát Windows környezeti változókon keresztül határozzuk meg. Így olyan rugalmasan konfigurálható adattárház környezetet építhetünk, melynek minden szerveren futtatható lesz.

Kapcsolódó anyagok:

• Adatforrások cseréje futásidőben
• Látja a gyerek SSIS csomag a szülő SSIS csomag változóit?

Felhasznált irodalom

• SQL Server 2005 Books Online: Package Configurations